REMARKS 



Claims 1-23 are pending in this application. The Office has rejected claims 1-23 
under 35 USC § 102(e) as being anticipated by Barkley (U.S. Pat. 6,202,066). This 
Office action is responsive to a communication filed on or about February 18, 2005 and 
has been made final, 

102(e^ Rejection of Claims 1 and 23 

Barkley does not show or suggest "providing a user-defined data type," as 
required by Applicant. The Office asserts that Barkley does teach a user defined data 
type in column 11, lines 20-25, in the form of deposit account information or employee 
information. Barkley does refer to "various files maintained by the bank's computer 
system ... such as files related to depositor account information and employee 
information," but this is not a user-defined data type. This passage simply states that 
there are files that have information related to bank accounts and bank employees. There 
is no teaching of a user-defined data type, nor does Barkley give any indication that user- 
defined data types are xised or even needed. It is true that all computer files have a 
structure and that a user somewhere defined the structure, but a person of ordinary skill in 
the art would understand that a file structure is a high level construct defined by 
combining one or more lower level constructs such as data types. The structure of a 
computer text file for example, would be defined as some number of bytes where each 
byte is defined as a character data type. In this example, a character data type would 
represent one ASCII character and the file would have how ever many bytes of this data 
type that are needed to store tiie text. Other files will have more complex structures that 
uses multiple data types, some of which could be user-defined data types. As shown in 
this example, the structure of a computer file and a user-defined data type or any data 
type is not the same and it is improper to equate them. 

The Office fiirther asserts tiiat the objects in column 11, lines 40-56, are user 
defined data types and are written by users. In this passage, Barkley teaches the use of a 
system structure called an Object Access Type (OAT) to control access to files and 
directories. Using OATs, a user can control who is allowed to access and manipulate 
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certain files. The term object as used in the OAT refers to files and directories that 
contain files. The OAT is not a user-defined data type and, as shown above, a file is not a 
user-defined data type. Barkley simply does not show or suggest the providing a user- 
defined data type. 

Barkley also does not show or suggest "providing security information for the 
user-defined data type," as required by Applicant. The Office asserts that "the object 
access type makes the objects secure by ensuring any access of the object conforms to 
defined security and permission attributes (Barkley, column 1 1, lines 40-56)." This may 
be true, but secure access to "objects" like those described by Barkley is not what 
Applicant is requiring. Applicant instead requires that seciuity information be provided 
for a user-defined data type. A user-defined data type is a description of data and not 
actual data . As discussed above, Barkley simply does not discuss or even hint at the use 
of user-defined data types. Barkley teaches the assignment of permissions to actual files 
and not to a user-defined data type as required by Applicant. 

102fe^ Rejection of Claim 17 

Barkley does not show or suggest a "secure data type associated with security 
information," as required Applicant. Applicant defines a secure data type as a user- 
defined data type (page 3, paragraph 2). As shown above, Barkley does not show or 
suggest a user-defined data type. Moreover, Barkley fails to show or suggest any "data 
type" whatsoever, Barkley also fails to show or suggest the association of security 
information with a data type, let alone a secure data type, as required by Applicant. 
Barkley's access control is associated with so-called "objects" that Barkley defines as "a 
passive entity that contains or receives information." (Barkley col. 6, lines 17-18.) 
Barkley's objects are clearly not the same as a data type, as that term is used by Applicant 
and understood by a person of ordinary skill in this area. These elements are missing 
from Barkley. 

lQ2fe) Rejection of Claim 5 

Barkley does not show or suggest a database that "store[s] an instance of data 
according to the first data type in the database system," as required by Applicant. 
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Barkley provides a detailed description of how his role/group permission system works 
with the Microsoft WindowsNT® operating system but gives almost no information on 
how the invention would work with a database system, except to say that a system 
administrator would define object access types (OAT). No further details are provided 
with respect to databases, Barkley simply does not show or suggest storing an instance of 
data, in a database, in the manner required by Applicant. 

The Office asserts that "Barkley teaches that objects and their attached respective 
object access type (permission/security granting objects) are stored in a database (column 
13, lines 62 - column 13, line 9)." (Office Action, Page 3, paragraph 5.) Applicant 
respectfully disagrees. Applicant can not find a passage that teaches storing anything in a 
database, much less storing an instance of data according to a data type in a database, as 
required. These elements are missing from Barkley. 

102(e) Rejection of the Dependent Claims 

Claims depending, from claims 1, 5, and 17 are allowable for at least the same 
reasons presented above. 
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CONCLUSION 



The Office has not shown that each of the required elements of AppHcant's claims 
are found within Barkley. The rejection is therefore improper and Applicant's claims are 
allowable over the prior art made of record. Applicant asks the Office to reconsider this 
application and allow all claims. Please charge any fees that might be due, excluding the 
issue fee, to deposit account 14-0225. 
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